1. Field of the Invention
The field of the invention is data processing, or, more specifically, methods, systems, and products for monitoring messages in a distributed data processing system.
2. Description of Related Art
Message oriented middleware (“MOM”) implements methods of communication between software components or applications. MOM systems implement both point-to-point functionality and publish-subscribe functionality. In a point-to-point domain, one source application (a ‘producer’) produces messages for one destination application (a ‘consumer’). Such a MOM system is often envisioned as a peer-to-peer facility in that any client application may function as either a producer or consumer depending on its function at any particular time. In client-server terms, that is, any client can produce or consume messages to or from any other client. Each MOM client typically connects to a messaging agent (sometime called a ‘queue manager’) that provides facilities for creating, sending, receiving, and reading messages.
MOM systems support distributed data communication that is loosely coupled and generally asynchronous. A producer component sends a message to a destination (typically a message queue), and a consumer recipient can retrieve the message from the destination. The producer and the consumer are not required to be available, either on-line or connected to one another for data communications in order to communicate. In fact, the producer does not need to know anything about the consumer, nor does the consumer need to know anything about the producer. The producer and consumer need to know only what message format and what destination (or message queue) to use. In this respect, messaging differs from tightly coupled technologies, such as the Common Object Request Broker Architecture (“CORBA”) or Java's Remote Method Invocation (“RMI”), which require a calling application to know a remote application's methods.
A “message” is a unit of information transmitted electronically from one computer application to another. Examples of messages generally include email messages and messages in data communications protocols such as HTTP or TCP/IP. Many messages in embodiments according to the present invention are units of information communicated in message oriented middleware (“MOM”). MOM messages differ somewhat from many other kinds of messages. Email messages, for example, implement human-readable communications from a person to a person or from a software application to a person. HTTP messages represent requests for particular computer resources and responses to such requests. A MOM messages, however, is used for communications between software applications and other software applications to implement business logic. That is, a MOM message generally communicates input data for, or output data from, operation of some form of business logic, accounting, on-line sales or marketing, financial calculations, security services, and so on. Examples of MOM systems include IBM's MQSeries products, JMS (the Java Message Service), and MSMQ (Microsoft Message Queuing).
As mentioned above, a MOM message generally communicates input data for, or output data from, operation of some form of business logic. Monitoring tools are currently available to monitor the performance of messaging systems by externally monitoring factors that affect messaging. Such conventional monitoring tools are currently available from a number of companies such as BMC Software™, Bristol™, Nastel™, QPasa™, Reconda™, and others that will occur to those of skill in the art. These conventional messaging monitoring tools do not use techniques available for monitoring other types of transactions that include embedding a transaction monitoring token at the beginning of a transaction and passing the monitoring token with each stage of a transaction or with each transaction. In such transaction monitoring tools, the transaction monitoring token is typically a data structure containing information defining the type of transaction being monitored, metrics used to measure the performance of the transaction, as well as information about the process engaged in the transaction. One such transaction monitoring application currently available is Tivoli Monitoring for Transaction Performance Version 5.1 (“TMTP™”) available from IBM®.
Conventional messaging systems do not provide for embedding a transaction monitoring token within the message at the source of the message and extracting the monitoring token at the destination because they do not provide a mechanism to embed the monitoring token into the message itself and they do not provide a mechanism to determine whether a consuming process is running on a remote client (in which case the remote client is the location where the monitoring token should be removed) or whether the consuming process is running on the server itself (in which case the server is where the monitoring token should be removed). There is therefore an ongoing need for improved methods, systems, and products for monitoring messages in a distributed data processing system capable of determining whether a call to get a message on a queue is made by a consuming process running on a remote client or by a consuming process running on the server and if the call to get the message is made by a process running on the server removing a monitoring token from the message.